#!/bin/bash
# Find the crate's lib.rs and types.rs to understand the structure
echo "=== Finding crate structure ==="
fd -t f "lib.rs|types.rs" src/

echo -e "\n=== Examining src/lib.rs ==="
cat src/lib.rs

echo -e "\n=== Examining src/types.rs ==="
cat src/types.rs

echo -e "\n=== Looking for parse_single_log or parse_frames in the crate ==="
rg -n "parse_single_log|parse_frames|sample_frames" src/ -g '!main.rs' -A 3 -B 1

#!/bin/bash
echo "=== Examining parse_frames implementation in detail ==="
cat src/parser/frame.rs | head -100

echo -e "\n=== Looking at the 10 frame limitation ==="
rg -n "sample_frames.len\(\) < 10" src/parser/frame.rs -B 5 -A 10

echo -e "\n=== Examining CSV export in crate ==="
cat src/export.rs | head -200

echo -e "\n=== Checking if there's a flag or option to control frame storage ==="
rg -n "ExportOptions|all.*frames" src/export.rs -B 2 -A 2

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: LICENSE_COMMERCIAL:1-4
Timestamp: 2025-08-29T19:52:05.099Z
Learning: nerdCopter prefers to avoid publishing personal information in license files for privacy and security reasons, as they are an individual maintainer rather than a company.

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: README.md:520-521
Timestamp: 2025-08-29T19:53:41.354Z
Learning: nerdCopter uses AGPL-3.0-or-later licensing for the bbl_parser project with a dual-licensing approach that includes a separate commercial license option.

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: CONTRIBUTING.md:9-14
Timestamp: 2025-08-21T20:25:45.741Z
Learning: nerdCopter prefers to keep CLA language general using "project maintainer" rather than specifying a legal entity name, as they are an individual maintainer without an associated company.

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: LICENSE_COMMERCIAL:0-0
Timestamp: 2025-08-29T20:15:04.624Z
Learning: nerdCopter prefers clear positive indicators (✅) when describing fixes rather than using ❌ symbols which can be confusing when describing what was corrected in a positive context.

#!/bin/bash
echo "=== Checking ExportOptions definition and store_all_frames field ==="
rg -n "pub struct ExportOptions" src/export.rs -A 15

echo -e "\n=== Checking parse_frames signature and store_all_frames usage ==="
rg -n "pub fn parse_frames" src/parser/frame.rs -A 3

echo -e "\n=== Checking the frame storage logic in parse_frames ==="
rg -n "store_all_frames|sample_frames.len\(\) < 10" src/parser/frame.rs -B 2 -A 5

echo -e "\n=== Checking CSV export logic - does it use sample_frames or debug_frames? ==="
rg -n "sample_frames|debug_frames" src/export.rs -B 2 -A 3 | head -80

echo -e "\n=== Checking how parse_single_log uses store_all_frames ==="
rg -n "store_all_frames" src/parser/main.rs -B 2 -A 2

echo -e "\n=== Checking Default implementation for ExportOptions ==="
rg -n "impl.*Default.*ExportOptions" src/export.rs -A 10

#!/bin/bash
echo "=== Checking Default implementation for ExportOptions ==="
rg -n "impl Default for ExportOptions" src/export.rs -A 15

echo -e "\n=== Full CSV export function to see complete logic ==="
cat src/export.rs | sed -n '160,230p'

echo -e "\n=== Checking how CLI calls the crate parser ==="
rg -n "parse_bbl_bytes_all_logs|ExportOptions" src/main.rs -B 2 -A 3 | head -50

echo -e "\n=== Checking csv_export.rs example to see how it's used ==="
cat examples/csv_export.rs

echo -e "\n=== Verify all tests pass by checking recent test results ==="
rg -n "#\[test\]|fn test_" src/ -c

#!/bin/bash
echo "=== Check CLI main.rs ExportOptions initialization for store_all_frames ==="
cat src/main.rs | sed -n '395,410p'

echo -e "\n=== Check if there's a Default impl (search more broadly) ==="
rg -n "Default" src/export.rs -B 1 -A 5

echo -e "\n=== Check parse_frames debug_frames logic more carefully ==="
cat src/parser/frame.rs | sed -n '370,395p'

echo -e "\n=== Check CSV export logic in detail - is it using the right priority? ==="
cat src/export.rs | sed -n '175,205p'

echo -e "\n=== See if CLI passes store_all_frames correctly ==="
rg -n "store_all_frames" src/main.rs -C 3

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: LICENSE_COMMERCIAL:1-4
Timestamp: 2025-08-29T19:52:05.099Z
Learning: nerdCopter prefers to avoid publishing personal information in license files for privacy and security reasons, as they are an individual maintainer rather than a company.

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: README.md:520-521
Timestamp: 2025-08-29T19:53:41.354Z
Learning: nerdCopter uses AGPL-3.0-or-later licensing for the bbl_parser project with a dual-licensing approach that includes a separate commercial license option.

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: CONTRIBUTING.md:9-14
Timestamp: 2025-08-21T20:25:45.741Z
Learning: nerdCopter prefers to keep CLA language general using "project maintainer" rather than specifying a legal entity name, as they are an individual maintainer without an associated company.

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: LICENSE_COMMERCIAL:0-0
Timestamp: 2025-08-29T20:15:04.624Z
Learning: nerdCopter prefers clear positive indicators (✅) when describing fixes rather than using ❌ symbols which can be confusing when describing what was corrected in a positive context.

#!/bin/bash
# Fetch issue #19 details using GitHub CLI
echo "=== Fetching issue #19 details ==="
gh issue view 19 --repo nerdCopter/bbl_parser --json title,body,number,state

echo -e "\n=== Searching for motorOutput in current PR code ==="
rg -n "motorOutput" src/ -B 3 -A 3

echo -e "\n=== Check AI summary for mentions of motorOutput or motor or array ==="
rg -i "motor|array.*sysconfig|comma.*separated" --no-filename << 'EOF'
src/parser/header.rs:
"""
## AI-generated summary of changes

- Adds logic so P frame definitions inherit field names from I frames when P field_names are empty, for both predictor and encoding header lines. This preserves P frame definitions by deriving from I when explicit P names are not provided.
- Removes support for parsing comma-separated arrays in sysconfig values for motorOutput and similar keys; now only a single integer value is accepted and stored, aligning with CLI behavior and leaving multi-value cases to defaults.



## Alterations to the declarations of exported or public entities

- No exported/public signature changes detected.

Estimated code review effort: Medium
"""
EOF

echo -e "\n=== Check the diff in src/parser/header.rs for motorOutput changes ==="
git diff master...HEAD -- src/parser/header.rs | grep -A 10 -B 10 "motorOutput" || echo "No motorOutput changes in header.rs diff"

echo -e "\n=== Look at current motorOutput parsing implementation ==="
cat src/parser/header.rs | sed -n '1,50p'

#!/bin/bash
# Get more context on the header parsing around sysconfig
echo "=== Full context of sysconfig parsing in header.rs ==="
rg -n "sysconfig|parse.*sysconfig" src/parser/header.rs -B 5 -A 15

echo -e "\n=== Check if there's any motorOutput processing in frame parsing ==="
rg -n "motorOutput|motor_output" src/parser/frame.rs -B 3 -A 3

echo -e "\n=== Check main.rs for motorOutput ==="
rg -n "motorOutput|motor_output" src/main.rs -B 2 -A 2

#!/bin/bash
# Check what master branch does with motorOutput parsing
echo "=== Checking master branch header.rs for motorOutput array parsing ==="
git show master:src/parser/header.rs | grep -A 20 -B 5 "motorOutput"

echo -e "\n=== Check if there are test files with motorOutput in them ==="
fd -e bbl -e txt . | head -5

echo -e "\n=== Look for any test data or examples with motorOutput ==="
rg -n "motorOutput" tests/ examples/ --no-ignore 2>/dev/null || echo "No test files found with motorOutput"

echo -e "\n=== Check the full decoder.rs context for PREDICT_MINMOTOR ==="
cat src/parser/decoder.rs | sed -n '235,255p'

#!/bin/bash
# Compare the parse_sysconfig_line function between master and this PR
echo "=== Master branch parse_sysconfig_line function ==="
git show master:src/parser/header.rs | sed -n '/fn parse_sysconfig_line/,/^}/p'

echo -e "\n=== Current PR parse_sysconfig_line function ==="
cat src/parser/header.rs | sed -n '/fn parse_sysconfig_line/,/^}/p'

echo -e "\n=== Check if there are any comments in issue #19 ==="
gh issue view 19 --repo nerdCopter/bbl_parser --json comments --jq '.comments[] | "\(.author.login): \(.body)"'

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: LICENSE_COMMERCIAL:1-4
Timestamp: 2025-08-29T19:52:05.099Z
Learning: nerdCopter prefers to avoid publishing personal information in license files for privacy and security reasons, as they are an individual maintainer rather than a company.

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: README.md:520-521
Timestamp: 2025-08-29T19:53:41.354Z
Learning: nerdCopter uses AGPL-3.0-or-later licensing for the bbl_parser project with a dual-licensing approach that includes a separate commercial license option.

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: CONTRIBUTING.md:9-14
Timestamp: 2025-08-21T20:25:45.741Z
Learning: nerdCopter prefers to keep CLA language general using "project maintainer" rather than specifying a legal entity name, as they are an individual maintainer without an associated company.

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: LICENSE_COMMERCIAL:0-0
Timestamp: 2025-08-29T20:15:04.624Z
Learning: nerdCopter prefers clear positive indicators (✅) when describing fixes rather than using ❌ symbols which can be confusing when describing what was corrected in a positive context.

#!/bin/bash
echo "=== Current PR branch parse_sysconfig_line function ==="
cat src/parser/header.rs | sed -n '/fn parse_sysconfig_line/,/^}/p'

echo -e "\n=== Verify motorOutput array parsing is present in current code ==="
rg -n "motorOutput.*contains.*," src/parser/header.rs -B 2 -A 10

echo -e "\n=== Check for any uncommitted changes ==="
git status --short

echo -e "\n=== Compare current header.rs to master ==="
git diff master...HEAD -- src/parser/header.rs | grep -A 15 -B 5 "motorOutput" || echo "No differences in motorOutput handling between master and PR"

#!/bin/bash
echo "=== Check what the test BBL file actually contains for motorOutput ==="
if [ -f "examples/test.BBL" ]; then
    echo "Examining test.BBL for motorOutput header:"
    strings examples/test.BBL | grep -i "motorOutput" | head -5
elif [ -f "test.BBL" ]; then
    echo "Examining test.BBL for motorOutput header:"
    strings test.BBL | grep -i "motorOutput" | head -5
else
    echo "Looking for any .BBL files to check motorOutput:"
    fd -e BBL -e bbl | head -3
fi

echo -e "\n=== Check if there's a test that specifically validates motorOutput parsing ==="
rg -n "motorOutput" tests/ src/ examples/ -g "*.rs" -C 2

echo -e "\n=== Verify the current HEAD commit on this branch ==="
git log --oneline -1

echo -e "\n=== Check if there are any recent commits that might have restored motorOutput ==="
git log --oneline -5 --all -- src/parser/header.rs

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: LICENSE_COMMERCIAL:1-4
Timestamp: 2025-08-29T19:52:05.099Z
Learning: nerdCopter prefers to avoid publishing personal information in license files for privacy and security reasons, as they are an individual maintainer rather than a company.

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: README.md:520-521
Timestamp: 2025-08-29T19:53:41.354Z
Learning: nerdCopter uses AGPL-3.0-or-later licensing for the bbl_parser project with a dual-licensing approach that includes a separate commercial license option.

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: CONTRIBUTING.md:9-14
Timestamp: 2025-08-21T20:25:45.741Z
Learning: nerdCopter prefers to keep CLA language general using "project maintainer" rather than specifying a legal entity name, as they are an individual maintainer without an associated company.

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: LICENSE_COMMERCIAL:0-0
Timestamp: 2025-08-29T20:15:04.624Z
Learning: nerdCopter prefers clear positive indicators (✅) when describing fixes rather than using ❌ symbols which can be confusing when describing what was corrected in a positive context.

#!/bin/bash
echo "=== Examining commit 08f82bc ==="
git show 08f82bc --stat

echo -e "\n=== Checking motorOutput changes in commit 08f82bc ==="
git show 08f82bc -- src/parser/header.rs | grep -A 20 -B 5 "motorOutput"

echo -e "\n=== Current state of parse_sysconfig_line function ==="
cat src/parser/header.rs | sed -n '/fn parse_sysconfig_line/,/^}/p'

echo -e "\n=== Verify motorOutput array parsing is present ==="
rg -n "motorOutput.*contains.*," src/parser/header.rs -B 2 -A 10

echo -e "\n=== Check CSV export priority logic in src/export.rs ==="
cat src/export.rs | sed -n '175,210p'

echo -e "\n=== Check if CSV export checks sample_frames.len() > 10 first ==="
rg -n "sample_frames.len\(\) > 10|debug_frames" src/export.rs -B 2 -A 3

echo -e "\n=== Verify CLI is using crate parser or own parser ==="
rg -n "parse_bbl_bytes_all_logs|own.*parser|streaming" src/main.rs -C 2 | head -40

echo -e "\n=== Check ExportOptions store_all_frames usage ==="
rg -n "store_all_frames" src/ -C 1

echo -e "\n=== Run clippy to check for any issues ==="
cargo clippy --all-targets 2>&1 | head -50

echo -e "\n=== Run tests ==="
cargo test 2>&1 | tail -30

#!/bin/bash
echo "=== Check how log.frames gets populated - what controls full vs sample? ==="
rg -n "frames:|frames =" src/parser/main.rs -B 3 -A 3

echo -e "\n=== Check ExportOptions definition ==="
cat src/export.rs | sed -n '/pub struct ExportOptions/,/^}/p'

echo -e "\n=== Check parse_frames signature ==="
rg -n "pub fn parse_frames" src/parser/frame.rs -A 5

echo -e "\n=== How does CLI call the crate parser? ==="
cat src/main.rs | sed -n '1390,1420p'

echo -e "\n=== Check if BBLLog has frames or sample_frames ==="
rg -n "pub struct BBLLog" src/types/log.rs -A 15

echo -e "\n=== Summary of remaining duplicate code in CLI ==="
echo "Checking if CLI still has own frame parsing..."
rg -n "fn.*parse.*frame" src/main.rs | head -10

echo -e "\n=== Check git log for recent commits ==="
git log --oneline -5

echo -e "\n=== Get file sizes to confirm deduplication ==="
wc -l src/main.rs src/lib.rs src/parser/frame.rs src/parser/header.rs

#!/bin/bash
echo "=== Check if parse_frames still has 10-frame limit or stores all frames ==="
rg -n "frames.len\(\) < 10|sample_frames.len\(\) < 10" src/parser/frame.rs -B 5 -A 5

echo -e "\n=== Check how frames vector is populated in parse_frames ==="
cat src/parser/frame.rs | sed -n '350,400p'

echo -e "\n=== Check the full return of parse_frames ==="
rg -n "fn parse_frames" src/parser/frame.rs -A 10

echo -e "\n=== Does parse_single_log in crate use all frames? ==="
cat src/parser/main.rs | sed -n '120,160p'

echo -e "\n=== Check for any TODO or FIXME comments ==="
rg -n "TODO|FIXME|XXX|HACK" src/ --type rust

echo -e "\n=== Check if there are any pending issues ==="
gh issue list --repo nerdCopter/bbl_parser --state open --limit 5

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: LICENSE_COMMERCIAL:1-4
Timestamp: 2025-08-29T19:52:05.099Z
Learning: nerdCopter prefers to avoid publishing personal information in license files for privacy and security reasons, as they are an individual maintainer rather than a company.

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: README.md:520-521
Timestamp: 2025-08-29T19:53:41.354Z
Learning: nerdCopter uses AGPL-3.0-or-later licensing for the bbl_parser project with a dual-licensing approach that includes a separate commercial license option.

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: CONTRIBUTING.md:9-14
Timestamp: 2025-08-21T20:25:45.741Z
Learning: nerdCopter prefers to keep CLA language general using "project maintainer" rather than specifying a legal entity name, as they are an individual maintainer without an associated company.

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: LICENSE_COMMERCIAL:0-0
Timestamp: 2025-08-29T20:15:04.624Z
Learning: nerdCopter prefers clear positive indicators (✅) when describing fixes rather than using ❌ symbols which can be confusing when describing what was corrected in a positive context.

#!/bin/bash
# Examine current GPS/GPX implementation in the codebase
echo "=== Current GPS home coordinate handling ==="
rg -n "home.*coord|GpsHomeCoordinate" src/ -B 2 -A 5

echo -e "\n=== Current GPX export implementation ==="
cat src/export.rs | sed -n '/pub fn export_to_gpx/,/^}/p' | head -100

echo -e "\n=== How GPS coordinates are currently used ==="
rg -n "gps_coordinates|home_coordinates" src/export.rs -B 3 -A 5

echo -e "\n=== Check GPS parsing and home coordinate extraction ==="
rg -n "parse.*gps|H.*frame.*gps|home" src/parser/frame.rs -B 2 -A 5 | head -80

echo -e "\n=== Check what data is stored in GpsHomeCoordinate ==="
rg -n "struct GpsHomeCoordinate" src/types/ -A 10

blackbox_tools GPS home coordinate reference point GPX export

blackbox-log-viewer GPS home coordinates betaflight

betaflight blackbox GPS H frame home coordinates format specification

#!/bin/bash
# Create detailed GitHub issue for GPS home coordinate enhancement
gh issue create --repo nerdCopter/bbl_parser \
  --title "Enhancement: Add GPS home waypoint to GPX export" \
  --body "## Context

This issue addresses the TODO comment at line 1497 in \`main.rs\`:
\`\`\`rust
_home_coords: &[GpsHomeCoordinate], // TODO: Use home coordinates for reference point
\`\`\`

## Current Status: Functionally Correct ✅

After deep analysis and comparison with [blackbox-tools](https://github.com/betaflight/blackbox-tools) and [blackbox-log-viewer](https://github.com/betaflight/blackbox-log-viewer), the current implementation is **already correct**:

### What's Working:
1. ✅ H frames (GPS home) are correctly parsed from blackbox logs (src/parser/frame.rs:343-367)
2. ✅ Home coordinates are correctly used as reference points during GPS decoding (src/parser/frame.rs:430-443)
3. ✅ GPS G frames contain deltas from home per Betaflight spec
4. ✅ Actual coordinates are calculated as: \`actual_position = home_position + delta\`
5. ✅ GPX export receives absolute lat/lon coordinates (not deltas)

### Why home_coordinates appears \"unused\" in GPX export:
The home coordinates are **already incorporated** into the GPS coordinates during frame parsing. By the time we reach GPX export, \`gps_coordinates\` contains absolute positions, so home coordinates don't need to be referenced again.

## Enhancement Opportunity: Home Waypoint Marker

While functionally correct, we could **enhance** GPX files by adding a home position waypoint for better visualization in mapping tools.

### Reference Implementation Analysis

#### Betaflight Blackbox Specification:
- H frames record GPS home position (latitude, longitude)
- H frames are logged periodically to maintain decoder state
- G frames store position deltas from home
- Predictor #7 (\"home-coord\") uses most recent H frame values

#### GPX 1.1 Specification:
GPX files support both track points (\`<trkpt>\`) and waypoints (\`<wpt>\`):
\`\`\`xml
<wpt lat=\"37.123456\" lon=\"-122.123456\">
  <name>Home</name>
  <sym>Flag</sym>
  <type>Home Position</type>
</wpt>
\`\`\`

### Proposed Enhancement

Add a home position waypoint to GPX exports when home coordinates are available. This would:
- ✅ Improve visualization in GPS mapping tools (Google Earth, Garmin BaseCamp, etc.)
- ✅ Provide a clear reference point for flight analysis
- ✅ Match behavior of some GPS analysis tools
- ✅ Remain backward compatible (waypoints are optional in GPX)

## Implementation Plan

### Phase 1: Add Home Waypoint to GPX Export (Est. 1-2 hours)

**File:** \`src/export.rs\`, function \`export_to_gpx\`

**Changes:**
1. Remove underscore prefix from \`_home_coordinates\` parameter (line 296)
2. After writing GPX metadata but before \`<trk>\` element, add waypoint logic:

\`\`\`rust
// Add home position waypoint if available
if let Some(home) = home_coordinates.first() {
    writeln!(
        gpx_file,
        r#\"  <wpt lat=\"{:.7}\" lon=\"{:.7}\">#\",
        home.home_latitude, home.home_longitude
    )?;
    writeln!(gpx_file, \"    <name>Home</name>\")?;
    writeln!(gpx_file, \"    <sym>Flag</sym>\")?;
    writeln!(gpx_file, \"    <type>Home Position</type>\")?;
    writeln!(gpx_file, \"  </wpt>\")?;
}
\`\`\`

3. Update the duplicate logic in \`src/main.rs\` function \`export_gpx\` (line 1497) - remove underscore and apply same logic

**Validation:**
\`\`\`bash
# Test with GPS-enabled log
cargo run -- test.BBL --gpx

# Verify GPX contains home waypoint
grep -A 4 '<wpt' output.gpx

# Validate GPX schema
xmllint --schema http://www.topografix.com/GPX/1/1/gpx.xsd output.gpx
\`\`\`

### Phase 2: Add Tests (Est. 1 hour)

**File:** New test in \`tests/gps_tests.rs\` or \`src/export.rs\`

\`\`\`rust
#[test]
fn test_gpx_includes_home_waypoint() {
    let home_coords = vec![GpsHomeCoordinate {
        home_latitude: 37.7749,
        home_longitude: -122.4194,
        timestamp_us: 0,
    }];
    
    let gps_coords = vec![/* test coordinates */];
    
    // Export GPX
    export_to_gpx(/* params */).unwrap();
    
    // Read and verify GPX contains waypoint
    let gpx_content = std::fs::read_to_string(\"output.gpx\").unwrap();
    assert!(gpx_content.contains(\"<wpt lat=\\\"37.7749\\\"\"));
    assert!(gpx_content.contains(\"<name>Home</name>\"));
}
\`\`\`

### Phase 3: Documentation (Est. 30 minutes)

**File:** \`README.md\` or \`docs/GPS_EXPORT.md\`

Document:
- GPX files now include home waypoint marker
- Home position derived from H frames in blackbox log
- Waypoint compatible with standard GPS tools

### Phase 4: Comparison with blackbox-tools (Est. 1 hour)

**Validation:**
1. Export GPX using blackbox_decode from reference implementation
2. Export GPX using bbl_parser
3. Compare waypoint handling (they may or may not include home waypoint)
4. Document any differences and rationale for bbl_parser's approach

## Alternative Considerations

### Option A: Only show home waypoint (implemented above)
- Pro: Simple, clear, widely compatible
- Con: Minimal information

### Option B: Add metadata to home waypoint
\`\`\`xml
<wpt lat=\"...\" lon=\"...\">
  <name>Home</name>
  <desc>GPS home position recorded at flight start</desc>
  <time>2025-03-26T05:00:00.000000Z</time>
  <sym>Flag</sym>
</wpt>
\`\`\`
- Pro: More informative, includes timestamp
- Con: Slightly more complex

### Option C: Add both home and multiple flight phases as waypoints
- Pro: Rich analysis capability
- Con: Complex, may clutter map view

**Recommendation:** Start with Option A (simple waypoint), consider Option B if users request more detail.

## Testing Checklist

- [ ] GPX with home coordinates includes waypoint
- [ ] GPX without home coordinates works (no waypoint)
- [ ] GPX validates against GPX 1.1 schema
- [ ] Google Earth imports and shows home marker
- [ ] Garmin BaseCamp displays home correctly
- [ ] Multiple logs in single file each show their home
- [ ] Backward compatibility: old GPX readers still work

## Reference Links

- [GPX 1.1 Schema](http://www.topografix.com/GPX/1/1/gpx.xsd)
- [Betaflight Blackbox Specification](https://github.com/betaflight/blackbox-tools)
- [blackbox-log-viewer](https://github.com/betaflight/blackbox-log-viewer) (shows home on map)
- [PR #17 Context](https://github.com/nerdCopter/bbl_parser/pull/17)

## Priority

**Low-Medium Priority** - This is a quality-of-life enhancement, not a bug fix. Current implementation is functionally correct and produces valid GPS tracks. The enhancement would improve user experience when visualizing flights in mapping tools.

## Estimated Effort

**Total: 3-4 hours**
- Implementation: 1-2 hours
- Testing: 1 hour  
- Documentation: 30 minutes
- Validation: 1 hour" \
  --label "enhancement" \
  --label "gps" \
  --label "documentation"

#!/bin/bash
# Check if issue was created despite label error
echo "=== Recent issues in the repository ==="
gh issue list --repo nerdCopter/bbl_parser --limit 5

echo -e "\n=== Available labels in the repository ==="
gh label list --repo nerdCopter/bbl_parser

echo -e "\n=== Search for the issue we just created ==="
gh issue list --repo nerdCopter/bbl_parser --search "GPS home waypoint" --limit 3

#!/bin/bash
# Create the issue again with valid labels only
gh issue create --repo nerdCopter/bbl_parser \
  --title "Enhancement: Add GPS home waypoint to GPX export" \
  --label "enhancement" \
  --label "documentation" \
  --body "## Context

This issue addresses the TODO comment at line 1497 in \`main.rs\`:
\`\`\`rust
_home_coords: &[GpsHomeCoordinate], // TODO: Use home coordinates for reference point
\`\`\`

## Current Status: Functionally Correct ✅

After deep analysis and comparison with [blackbox-tools](https://github.com/betaflight/blackbox-tools) and [blackbox-log-viewer](https://github.com/betaflight/blackbox-log-viewer), the current implementation is **already correct**:

### What's Working:
1. ✅ H frames (GPS home) are correctly parsed from blackbox logs (src/parser/frame.rs:343-367)
2. ✅ Home coordinates are correctly used as reference points during GPS decoding (src/parser/frame.rs:430-443)
3. ✅ GPS G frames contain deltas from home per Betaflight spec
4. ✅ Actual coordinates are calculated as: \`actual_position = home_position + delta\`
5. ✅ GPX export receives absolute lat/lon coordinates (not deltas)

### Why home_coordinates appears \"unused\" in GPX export:
The home coordinates are **already incorporated** into the GPS coordinates during frame parsing. By the time we reach GPX export, \`gps_coordinates\` contains absolute positions, so home coordinates don't need to be referenced again.

## Enhancement Opportunity: Home Waypoint Marker

While functionally correct, we could **enhance** GPX files by adding a home position waypoint for better visualization in mapping tools.

### Reference Implementation Analysis

#### Betaflight Blackbox Specification:
- H frames record GPS home position (latitude, longitude)
- H frames are logged periodically to maintain decoder state
- G frames store position deltas from home
- Predictor #7 (\"home-coord\") uses most recent H frame values

#### GPX 1.1 Specification:
GPX files support both track points (\`<trkpt>\`) and waypoints (\`<wpt>\`):
\`\`\`xml
<wpt lat=\"37.123456\" lon=\"-122.123456\">
  <name>Home</name>
  <sym>Flag</sym>
  <type>Home Position</type>
</wpt>
\`\`\`

### Proposed Enhancement

Add a home position waypoint to GPX exports when home coordinates are available. This would:
- ✅ Improve visualization in GPS mapping tools (Google Earth, Garmin BaseCamp, etc.)
- ✅ Provide a clear reference point for flight analysis
- ✅ Match behavior of some GPS analysis tools
- ✅ Remain backward compatible (waypoints are optional in GPX)

## Implementation Plan

### Phase 1: Add Home Waypoint to GPX Export (Est. 1-2 hours)

**File:** \`src/export.rs\`, function \`export_to_gpx\`

**Changes:**
1. Remove underscore prefix from \`_home_coordinates\` parameter (line 296)
2. After writing GPX metadata but before \`<trk>\` element, add waypoint logic:

\`\`\`rust
// Add home position waypoint if available
if let Some(home) = home_coordinates.first() {
    writeln!(
        gpx_file,
        r#\"  <wpt lat=\"{:.7}\" lon=\"{:.7}\">#\",
        home.home_latitude, home.home_longitude
    )?;
    writeln!(gpx_file, \"    <name>Home</name>\")?;
    writeln!(gpx_file, \"    <sym>Flag</sym>\")?;
    writeln!(gpx_file, \"    <type>Home Position</type>\")?;
    writeln!(gpx_file, \"  </wpt>\")?;
}
\`\`\`

3. Update the duplicate logic in \`src/main.rs\` function \`export_gpx\` (line 1497) - remove underscore and apply same logic

**Validation:**
\`\`\`bash
# Test with GPS-enabled log
cargo run -- test.BBL --gpx

# Verify GPX contains home waypoint
grep -A 4 '<wpt' output.gpx

# Validate GPX schema
xmllint --schema http://www.topografix.com/GPX/1/1/gpx.xsd output.gpx
\`\`\`

### Phase 2: Add Tests (Est. 1 hour)

**File:** New test in \`tests/gps_tests.rs\` or \`src/export.rs\`

\`\`\`rust
#[test]
fn test_gpx_includes_home_waypoint() {
    let home_coords = vec![GpsHomeCoordinate {
        home_latitude: 37.7749,
        home_longitude: -122.4194,
        timestamp_us: 0,
    }];
    
    let gps_coords = vec![/* test coordinates */];
    
    // Export GPX
    export_to_gpx(/* params */).unwrap();
    
    // Read and verify GPX contains waypoint
    let gpx_content = std::fs::read_to_string(\"output.gpx\").unwrap();
    assert!(gpx_content.contains(\"<wpt lat=\\\"37.7749\\\"\"));
    assert!(gpx_content.contains(\"<name>Home</name>\"));
}
\`\`\`

### Phase 3: Documentation (Est. 30 minutes)

**File:** \`README.md\` or \`docs/GPS_EXPORT.md\`

Document:
- GPX files now include home waypoint marker
- Home position derived from H frames in blackbox log
- Waypoint compatible with standard GPS tools

### Phase 4: Comparison with blackbox-tools (Est. 1 hour)

**Validation:**
1. Export GPX using blackbox_decode from reference implementation
2. Export GPX using bbl_parser
3. Compare waypoint handling (they may or may not include home waypoint)
4. Document any differences and rationale for bbl_parser's approach

## Alternative Considerations

### Option A: Only show home waypoint (implemented above)
- Pro: Simple, clear, widely compatible
- Con: Minimal information

### Option B: Add metadata to home waypoint
\`\`\`xml
<wpt lat=\"...\" lon=\"...\">
  <name>Home</name>
  <desc>GPS home position recorded at flight start</desc>
  <time>2025-03-26T05:00:00.000000Z</time>
  <sym>Flag</sym>
</wpt>
\`\`\`
- Pro: More informative, includes timestamp
- Con: Slightly more complex

### Option C: Add both home and multiple flight phases as waypoints
- Pro: Rich analysis capability
- Con: Complex, may clutter map view

**Recommendation:** Start with Option A (simple waypoint), consider Option B if users request more detail.

## Testing Checklist

- [ ] GPX with home coordinates includes waypoint
- [ ] GPX without home coordinates works (no waypoint)
- [ ] GPX validates against GPX 1.1 schema
- [ ] Google Earth imports and shows home marker
- [ ] Garmin BaseCamp displays home correctly
- [ ] Multiple logs in single file each show their home
- [ ] Backward compatibility: old GPX readers still work

## Reference Links

- [GPX 1.1 Schema](http://www.topografix.com/GPX/1/1/gpx.xsd)
- [Betaflight Blackbox Specification](https://github.com/betaflight/blackbox-tools)
- [blackbox-log-viewer](https://github.com/betaflight/blackbox-log-viewer) (shows home on map)
- [PR #17 Context](https://github.com/nerdCopter/bbl_parser/pull/17)

## Priority

**Low-Medium Priority** - This is a quality-of-life enhancement, not a bug fix. Current implementation is functionally correct and produces valid GPS tracks. The enhancement would improve user experience when visualizing flights in mapping tools.

## Estimated Effort

**Total: 3-4 hours**
- Implementation: 1-2 hours
- Testing: 1 hour  
- Documentation: 30 minutes
- Validation: 1 hour

---

**AI Implementation Instructions:**

If implementing this enhancement, follow the iterative approach:

1. **Start with Phase 1** - core functionality
2. **Validate output** with sample GPS logs before proceeding
3. **Add tests in Phase 2** to prevent regressions
4. **Complete documentation** only after functionality is confirmed working
5. **Optional Phase 4** - compare with reference tools if desired

Each phase should be a separate commit for easy review and potential rollback if needed."

echo ""
echo "=== Verify issue was created ==="
gh issue list --repo nerdCopter/bbl_parser --limit 3

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: LICENSE_COMMERCIAL:1-4
Timestamp: 2025-08-29T19:52:05.099Z
Learning: nerdCopter prefers to avoid publishing personal information in license files for privacy and security reasons, as they are an individual maintainer rather than a company.

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: README.md:520-521
Timestamp: 2025-08-29T19:53:41.354Z
Learning: nerdCopter uses AGPL-3.0-or-later licensing for the bbl_parser project with a dual-licensing approach that includes a separate commercial license option.

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: CONTRIBUTING.md:9-14
Timestamp: 2025-08-21T20:25:45.741Z
Learning: nerdCopter prefers to keep CLA language general using "project maintainer" rather than specifying a legal entity name, as they are an individual maintainer without an associated company.

Learnt from: nerdCopter
Repo: nerdCopter/bbl_parser PR: 2
File: LICENSE_COMMERCIAL:0-0
Timestamp: 2025-08-29T20:15:04.624Z
Learning: nerdCopter prefers clear positive indicators (✅) when describing fixes rather than using ❌ symbols which can be confusing when describing what was corrected in a positive context.